Terminbuchungssystem mit Techniken des Domain Driven Design

Die Projektidee

Frederic und ich haben uns für das CodeCamp vorgenommen, eine Terminbuchungsapp für „unseren Koch“ Marcel umzusetzen. Marcel bereitet uns schon seit vielen Monaten immer donnerstags bei Cap3 leckere vegetarische Gerichte zu (https://www.facebook.com/Mittagshoch).

Damit er eine Einschätzung hat, wie viele hungrige Cap3ler ein Mittagessen wünschen, nutzen wir momentan eine Doodle-Liste. Marcel verfolgt die Vision, sich mit seinem Geschäftsmodell an lokale Unternehmen und deren Mitarbeiter zu richten, und über gesundes und saisonales Essen am Arbeitsplatz eine Kontakt-Plattform zum Vernetzen anzubieten. Hierfür gilt es, verbindliche Zusagen der Teilnehmer zu erhalten, sowie bestenfalls auch schon im Voraus eine elektronische Bezahlung einzuholen. Marcel hat sein Mittagessen-Buchungssystem vor dem CodeCamp bei uns gepitcht und konnte ein Team für die prototypische Umsetzung seiner Idee gewinnen.

Wir nutzten dieses Projekt, um u. a. eine Methodik des Domain Driven Designs zu üben – das Event Storming nach Alberto Brandolini. Zunächst definierten wir alle Domain Events im Kontext der Idee (je Event ein orangenes Post-it), um diese anschließend zu Aggregaten zu gruppieren. Danach definierten wir externe Systeme – in unserem Falle die Bezahlung über PayPal (lilafarbenes Post-it) – und Prozesse bzw. Interaktionen (blaue Post-its) der zukünftigen Benutzer der App. Das klappte so weit schon ganz gut und die beim Event Storming entstehenden Diskussionen waren auf jeden Fall sehr aufschlussreich.

Die Entwicklung

Frederic und ich nutzen das entstandene Bild, um uns nach kurzer Einweisung von Nicolas am Event Sourcing zu versuchen. Das Event Sourcing beschreibt eine Methodik der Software-Entwicklung, bei der jede Veränderung des System-Zustands als Event gespeichert wird.

Dies hat zur Folge, dass – im Gegensatz zu Systemen, die nur den aktuellen Zustand vorhalten – immer die komplette Historie aller Änderungen verfügbar ist, sodass praktisch jeder beliebige Zustand des (Teil-)Systems zu jedem Zeitpunkt wiederhergestellt werden kann. Gerade bei Systemen, bei denen die Verfügbarkeit der Historie von Daten essenziell ist (z. B. Finance IT), ist der Einsatz von Event Sourcing meistens sinnvoll.

Durch die Verfügbarkeit der Historie können auch noch zu einem späteren Zeitpunkt bestimmte Abfragen an das System gestellt werden (z. B. wie viele Kunden haben 5 Minuten vor einer Bestellung Waren aus dem Warenkorb gelöscht?).

Durch die andere Art der Persistierung war diese Methodik für uns zunächst ungewohnt und erforderte eine andere Denkweise. Durch den Einsatz der Programmiersprache „Scala“ sowie „Akka-Persistence“ – einem Framework, welches Event Sourcing ermöglicht – konnten wir schnell erste Erfolge erzielen. Während wir also mit der Programmierung losgelegt haben, skizzierte unser User-Interface-Designer Ben anhand der Dokumentation zusammen mit Felix und Kira die einzelnen Sichten der App und machte sich anschließend an die Umsetzung der konkreten Entwürfe.

Zurück zu Frederics und meiner Entwicklung: So richtig gestartet mit der Umsetzung haben wir erst am Freitagmittag, das heißt uns blieben auch nur noch ca. 1,5 Tage für die weitere Umsetzung. Leider etwas zu wenig Zeit für eine komplette Entwicklung des Systems. Was wir allerdings auf die Beine stellen konnten ist das Grundsystem mit Event Sourcing, sodass später ohne viel weiteren Aufwand weiterentwickelt werden kann.

Fazit

Wir sind mit dem Projektergebnis zufrieden, obwohl wir uns gewünscht hätten, etwas mehr Zeit zu haben, um noch tiefer in das Thema einzusteigen. Durch dieses Projekt haben wir die Erkenntnis gewonnen, dass Software- Systeme von einer Event Sourcing-Architektur profitieren können. Event Sourcing wird zukünftig auch in Kundenprojekten bei Cap3 eingesetzt werden.